Long Term Evolution (LTE) technology, introduced in 3GPP Release 8, is the next major step in mobile radio communications. It will give a superior user experience and support even more demanding applications, such as interactive TV, user-generated videos, advanced games, and professional services. LTE uses OFDM (orthogonal frequency-division multiplexing) radio access technology together with advanced antenna technologies.
In addition to LTE, 3GPP has specified a flat, IP-based network architecture as part of the System Architecture Evolution (SAE) effort. The aim and design of the LTE/SAE architecture and concepts are to efficiently support mass-market usage of any IP-based service. The architecture is based on, and evolved from, existing GSM/WCDMA core and radio access networks to facilitate simplified operations and smooth cost-effective deployment.
The LTE/SAE architecture reduces operating expenses and capital expenditures. The new, flat architecture, for example, means that only two node types (base stations and gateways) must scale in capacity in order to accommodate large increases in data volumes. In addition, 3GPP and 3GPP2 have agreed to optimize interworking between CDMA and LTE/SAE. CDMA operators will thus also be able to evolve their networks to LTE-SAE and benefit from huge economies of scale and global chipset volumes.
The architecture of the LTE/SAE is shown in FIG. 1. There is only traffical node type in the Radio Access Network (eNodeB), with two node types in the SAE core network (SAE CN), namely a Mobility Management Entity (MME), which takes care of control signalling, and a SAE Gateway (SAE-GW), which takes care of the user data. The SAE-GW is a working name and consists of two different parts, namely the Serving Gateway and the PDN Gateway that are well defined in for example 3GPP TS 23.401. All of these nodes are interconnected by an IP network.
There are three major protocols and interfaces (illustrated in FIG. 1) between these node types. These are S1-MME between eNodeB and MME, S1-U between eNodeB and SAE-GW (or more correctly between the eNodeB and Serving Gateway), and X2 between eNodeBs. The corresponding protocols used in these interfaces are S1AP (S1 Application Protocol), GTP-U (GPRS Tunnelling Protocol User plane), and X2AP (X2 Application Protocol). All of these protocols and interfaces are IP-based. In addition, the network may contain other nodes that are part of the above interface, for example a Home eNodeB Gateway (HeNB GW) between a Home eNodeB (HeNB) and the rest of the nodes in the network.
A common scenario for an operator to connect the LTE RAN and SAE CN involves the leasing of transport capacity with a certain Service Level Agreement (SLA), e.g. specific bandwidth and QoS support, from an Internet Service Provider. This hired transport capacity is treated as un-secure since the traffic may be mixed with traffic from other users and may traverse through, for example, parts of the Internet. We also assume that the core network nodes are located in a secured intranet (so called trusted domain). In order to provide a secured communication between an eNodeB and a SAE CN, a security gateway (SEGW) is introduced in the interface between the Internet and intranet. IPSec tunnels are used in order to connect the eNodeBs towards the core network intranet via the SEGWs.
FIG. 2 shows some examples in which eNodeBs (in the Internet) are connected to the SAE CN nodes using IPSec tunnels towards the SEGWs. The S1-MME and the S1-U are established over the IPSec tunnels. It is also shown that an X2 interface between two eNodeBs can traverse either through one or two SEGW(s) depending on whether the eNodeBs are connected to the same or to different SEGW(s).
There are several factors which impact the pricing of the leased transport capacity. These could be for example bandwidth, Quality of Service (QoS), and the number of public IP addresses provided. In order to minimize the need for public IP addresses, an eNodeB can be located behind a firewall with Network Address Translation (NAT). The NAT is normally allocated one IP address from a pool of publicly registered IP addresses by the ISP. It then performs source (for outgoing packets) and destination (for incoming packets) address translation between private and public IP address. Use of a NAT requires that IPSec setup may be done for example with the following features in order to bypass the NAT and allow the eNodeBs to communicate with the SEGWs and the nodes in the intranet:                Tunnel mode        ESP        UDP encapsulation of IPSec ESP Packets (RFC 3948)        Intranet IP address allocation during IPsec tunnel establishment via, for example, IKEv2 signalling or DHCP.        
FIG. 3 shows the different possibilities for eNodeB topology locations that are important in relation to the establishment of the X2 interface. These are:                1. Intranet—eNodeB is located within the same secure domain (i.e. intranet) as the core network nodes and some other eNodeBs.        2. Internet with no NAT—eNodeB is located outside the secure domain, i.e. in the Internet. In order to access the secure domain, eNodeB needs to establish an IPSec tunnel towards the SEGW.        3. Internet with NAT—eNodeB is located outside the secure domain, i.e. in the Internet. In order to save the amount of public IP addresses (or other reasons), the eNodeB is located behind a NAT. In this case, an IPSec tunnel is also needed between eNodeB and SEGW.        
There are two different methods for establishing an X2 connection between two eNodeBs when both eNodeBs are located in the Internet. The first method is routing traffic through the already established IPSec tunnels between eNodeBs and SEGWs. The advantage of this method is simplicity, since all the necessary connections are already established during initial setup of the S1 interfaces when IPsec tunnels are also established between the eNodeBs and the SEGWs. The drawback of this method is that the X2 data will go through at least two encryption/decryption chains and will introduce additional and unnecessary delays in the X2 interface, and that additional capacity is needed in the SEGW. This is not desirable from either a mobility or performance point of view.
A second method that can be applied when at least the destination eNodeB is not located behind a NAT, is to establish a direct IPSec tunnel between the eNodeBs. The advantage of this method is that the X2 data will only go through one single encryption/decryption chain. The drawback is that, for each X2 connection, certification between the eNodeBs is needed (i.e. to authenticate the other eNodeB and to verify that the eNodeB is allowed to establish the IPsec tunnel), in turn requiring a complex certification structure on the eNodeB if Automatic Neighbor Relation (ANR) is involved in the X2 establishment (since X2 establishment will be done in a more “ad hoc” manner, and each eNodeB needs to have capability to certify any potential “neighbor” during run-time).